Copyright: Copyright © 1997 RealSoft


A Binary Large Object is a collected group of Binary Data.

Bitmaps, streams, dynarrays, and DBASE bitmaps store

data in Binary Properties.


Binary Properties

The binary properties of a Delphi Form file are those properties of components that require

streamed storage, or are stored as a Binary Large Object.  These properties can create

extremely long procedures and often are unwanted.  However loading such properties from file

creates yet another outside file that cannot be compiled in, and often such properties cannot

be stored within a file.

The Binary Properties option is, therefore, defaulted to always include.  Not including these lines

will simply not include any lines to set the the associated property of such components.  The

option "Prompt Me" is given for the opportunity to include the Binary Properties of select

components.

Including the Binary Property of an object will create a constant array of THex, or hexadecimal

based numbers.  These arrays are stored within the const section of the CreateForm procedure,

to avoid the use of large amounts of global declaration.  In extremely large forms, however, the

CreateForm procedure may become too long and may generate the compiler error "Program

segment too large."  In such a case moving the arrays to the global const section may help.

The Form Parser attempts to write the Binary data into a constant array and then, at runtime,

convert the constant array into a memory stream, using HextoStream, and then Loads the data

from stream.  The component property must have an associated LoadFromStream method to

enable this process.  The Form Parser automatically references the Picture property of an

TImage.


Component Events

Component Events are not included within the output of the parsed file.  Transferring the

events within the parsed class can be done by declaring the associated method into the

public (or private section) and then placing the method after the implementation line, as

with any procedure in a typical form.  After the method has been added to the parsed class

set the event equal to the method.  The parsing of Component events is an option that will be

available in a later version of the Form Parser.

Example

  TProc_dlAddComp = class

  private

    procedure CreateForm1;

  public

    dlAddComp : TForm;

    Label1 : TLabel;

    Label2 : TLabel;

    btnAdd : TButton;

    btnSkip : TButton;

    RadioGroup1 : TRadioGroup;

    btnHelp : TButton;

    procedure FormShow(Sender: TObject);

    constructor Create;

    destructor Destroy; override;

  end;

.

.

.

procedure TProc_dlAddComp.FormShow(Sender: TObject);

begin

  label2.caption:= 'Do you want to add ' + ObjType + '?';

end;

.

.

.

  with dlAddComp do begin

    BorderIcons := [ ];

    BorderStyle := bsDialog;

    Caption := 'Add Component';

    ClientHeight := 156;

    ClientWidth := 242;

    Font.Color := clWindowText;

    Font.Height := -11;

    Font.Name := 'MS Sans Serif';

    Font.Style := [];

    OnShow := FormShow;

    PixelsPerInch := 96;

    { TextHeight := 13; }

    end;


Component Lists

The Component lists are used by the Form Parser when adding each component to the parsed

output.  Component properties may or may not be added based on the list the component is found.

The default lists include all native Delphi components.  Unknown components must be added to

the list, as there is no method for determining the ancestry of the Component string.  Components

added to more than one list will use the settings of the highest descendant (i.e. TWinControl).

TComponents

TControls

TWinControls

To exit the Component List screen, click Return.


Contents
Form Parser Contents

What is a Delphi Form Parser?

Form Class

Program Segment too Large

Options

  Defaults

  Defined Fields

  Binary Properties

  String Properties

  Textheight Property

  Component Events

  Adding Parent Property

  Adding Top / Left Properties

Component Lists

  TComponents

  TControls

  TWinControls

Registering the trial version

Copyright 1997 RealSoft Development

Support: www.realsoftdev.com


Defaults

The Options menu and the Component Lists are saved on the exit of the screen.  These changes

are loaded from a *.dat file each time the parser is run to enable your preferences.  By Clicking

Default on either of these screens the Options or the visible list will reset to the defaults choices

that come with the form parser.  All previous changes will be lost, and the *.dat file will be saved

with the settings.


Defined Fields

Component developers often wish to have all components within a class begin with "F" designating

an internal field (as "T" designates Type).  Selecting this option will add an "F" before the name of

every component on the form, and the form itself.  This property is defaulted to false.


Form Class

The Class created by the Form Parser can be used in multiple ways.  The class can be saved as a

new unit and be used by including the unit name in the uses clause your project file or component.

The Class declaration and support procedures can also be copied into an existing unit.

When creating the class for use, you must include an instance of the Class in the var section and

then create the variable instance.

Example

procedure TMyForm.Button1.Click(Sender : TObject);

var

  Proc_Form1 : TProc_Form1;

begin

  Proc_Form1:= TProc_Form1.Create;

  Proc_Form1.Form1.Show;

  Proc_Form1.Free;

end;


Options

The Form Parser's options allow you to customize the output of your parsed form.  Options are

given that enable you to shorten or lengthen the amount of code produced as well as format your

code to ensure the compiling of the parsed output.  All changes made to the Options and the

Component lists are saved on exit of the screen.

Defined Fields

Binary Properties

String Properties

Textheight Property

Component Events

Adding Parent Property

Adding Top / Left Properties

To exit the options menu, click Return.


Parent Property

Components based on TComponent, all non-visual components, are owned by the form but

are not the children of any sub component.  Setting the Parent property of such components

raises an error on compiling.  All components found on the TComponent list found within the

options menu, will not add a parent property to the parsed output, however, unknown components

and custom components not added to the list will use the default setting.  If the component is

based on TComponent and the Parent property is added, simply delete the line from the parsed

output.

See Also

Top / Left Properties


Program Segment too Large

In extremely long forms the CreateForm procedure can often reach the compiler limit for procedure

length. Moving large constant arrays in the global const section most often corrects this problem,

but if the procedure is still too long you must manually split the CreateForm procedure.  Splitting

the procedure can be done by creating a second procedure, "CreateForm2" for example, declaring

it in the private section of the Form Class, and then placing the remaining code within

"CreateForm2." Simply call "CreateForm2" at the end of your initial CreateForm procedure.


Registering the trial version

If you are evaluating a trial edition of this product,

you may register on Compuserve, or the internet.

Source code for components is always included.

Product: Form Parser

Price (US): $25.00

CIS Reg: 13150


String Properties

The string properties of a Delphi Form file are those properties of components that require

multiple lines of strings.  Often these properties can lengthen a procedure and are unwanted.

However loading the strings from a text file creates yet another outside file that cannot be

compiled in.

The String Properties option is, therefore, defaulted to always include.  Not including these lines

will simply not include any lines to set the text of such components.  The option "Prompt Me"

is given for the opportunity to include the String Properties of select components.


TComponents

Description

The TComponent component is the most basic, abstract starting point for all components. Every

item the user can manipulate in the form designer is a descendant of TComponent, and all

components inherit some basic behavior from TComponent.

Components based on TComponent, all non-visual components, are owned by the form but

are not the children of any sub component.  Setting the Parent property of such components

raises an error on compiling.  All components found on the TComponent list found within the

options menu, will not add a parent property to the parsed output, however, unknown components

and custom components not added to the list will use the default setting.  If the component is

based on TComponent and the Parent property is added, simply delete the line from the parsed

output.


TControls

Description

The TControl component is the abstract component type for all controls. Controls are visual

components, meaning the user can see them and manipulate them at run time. TControl provides

all the properties, methods, and events that all controls need. Those items required for all controls

are declared as public, and appear in all controls. Many other items that might be useful to

controls are declared as protected, meaning that you can publish them in components you derive

from TControl or one of its descendant types.

TControls include TGraphicControls such as TImage and TPaintbox.  TControls are visual controls

that do not have a tabstop.  Windows does not maintain a handle for standard TControls.


TWinControls

Description

The TWinControl component is the abstract component type for windowed controls, which are

controls with window handles, including the standard Windows controls.

Components based on TWinControl, most editing components, are the children of other

components, for example, the Form.  The TEdit, TCombobox, and TPanel descend from the base

TWinControl.  Most controls with a taborder property are descendants of the base TWinControl.

Descendants from TWinControls require the addition of the Parent property to the output of the

parsed file.  The Top and left properties are also needed to give the visual orientation of the

component.


Textheight Property

The Textheight property is used by Delphi Form files, but is unnecessary when creating forms

on the fly.  The Form Parser gives you the option to include this property only as a comment.

If the checkbox is not selected the property will not be added at all.


Top/Left Properties

Components based on TComponent, all non-visual components, are owned by the form but are not

the children of any sub component.  Setting the Left and Top properties of such components

raises an error on compiling, as the position properties are "dummy" properties, and unused by the

non-visual components.  All components on the TComponent list found within the options menu,

will not add Top or Left properties to the parsed output, however, unknown components and custom

components not added to the list will use the default setting.  If the component is based on

TComponent and Top or Left properties are added, simply delete the lines from the parsed output.

Components on the TControl and TWinControl lists will add the Top and left properties to the

parsed output.

See Also

Parent Property


What is a Delphi Form Parser?

By default Delphi generates a resource file, or Delphi Form File (.dfm) which accompanies a form

created using the Delphi editor.  Having the form in the resource eliminates much of the overhead

and work required when programmatically creating the form.  The need to eliminate the outside

resource file (the .dfm) is most easily realized by component authors distributing source code.

When distributing the source the Delphi Form File must be included as it is not yet compiled into

a DCU.  Floating form files are easily lost or changed by end users, often creating component

errors.  Component developers are not the only beneficiaries of a "Form Procedure" however,

developers working on Large projects often find it useful to eliminate one or more small dialog

forms.

The alternative to including the Delphi Form File when a form is necessary is to create it "on the

fly", or more simply programmatically create and set the properties of each component on the

form, within a Delphi unit.  This can become a very tedious task, especially with complex forms.

Designing and updating these hand-coded forms can be equally unbearable.

The Form Parser handles the tedium of hand-coding for you.  Each line of the Delphi Form File is

interpreted by the Form Parser and added to a Delphi Unit.  You can retain a normal Form file

outside of your project, and the entire form can be converted into a Form Class that can be

included into your unit.  To change your Parsed Form simply change your original form file and

re-parse.

The speed of the form procedure often exceeds that of the DFM as well, as the properties are

immediately set and not read from a resource.